In modern service-based systems, there are frequently many (often thousands) of destinations that may implement a given task. However, each destination may have different capabilities and constraints or limitations with respect to the task. If a client is familiar with a destination, the client can use this information to guide the configuration and invocation of the task. If, though, the client has not chosen the destination at the time of a job invocation (e.g. likely the case if a service is intermediating between the client and the destination), the client does not have a way to understand how to configure the task. Typically, it is not reasonable for the client to know the capabilities of each potential individual destination, as there could possibly be thousands of potential destinations.
One conventional solution to this issue includes limiting the system functionality to a “least common denominator” feature set. Unfortunately, this solution limits the client's access to the full capabilities of the eventual target destination. Another conventional solution to this issue includes forcing the client to limit the destination choice to a single destination as the client's target. Unfortunately, this solution either limits the client's options (e.g. it is only exposed to the capabilities of a single target) or requires the client to repeatedly query individual destinations for their capabilities. This solution has the potentially undesirable consequence of consuming an excessive amount of time or possessing inordinate complexity.
It would be desirable therefore, to provide advancements to the art that overcome these and other disadvantages.